用 Sloth 自动生成告警规则：从手写到自动化的 SLO 工程实践 原创

SRE 工具实战 · 深度指南 | 约 7000 字 | 预计阅读 20 分钟 | Sloth v0.16+

上一篇《SLO 落地实战》里，我们手写了 4 条双窗口燃烧率告警规则。如果你只有一个服务、一个 SLI，手写还能接受。但现实是：3 个服务 × 3 个 SLI = 9 套规则 = 36 条 PromQL 告警表达式。改一个 SLO 目标，36 条全要改。

这就是 Sloth 要解决的问题——用声明式 YAML 定义 SLO，自动生成所有 Prometheus recording rules 和 alert rules。本文深入讲透 Sloth 的安装、配置、生成规则解析和高级用法。

---

1 为什么需要 Sloth

先看看手写告警规则的痛点有多大。一个 99.9% 可用性 SLO，需要手写的规则包括：

规则类型	数量	内容
SLI recording rules	8 条	5m/30m/1h/2h/6h/1d/3d/30d 各一条错误率计算
Meta recording rules	7 条	SLO 目标、错误预算、燃烧率、剩余预算等
Page alert rules	2 条	1h/5m ×14.4 + 6h/30m ×6
Ticket alert rules	2 条	3d/6h ×1 + 1d/2h ×3
合计	19 条	每个 SLI 19 条规则

9 个 SLI 就是 171 条规则。手动维护这些规则的三个致命问题：

❌ 问题一：PromQL 易错 手写 sum(rate(...)) / sum(rate(...)) 时，括号匹配、label 过滤、窗口大小任何一个写错，规则静默失效——Prometheus 不会报错，只是算出错误的数字。

❌ 问题二：SLO 目标变更成本高 从 99.9% 改成 99.95%，需要更新 19 条规则里的阈值乘数。手动查找替换容易漏改，且没有验证手段。

❌ 问题三：格式不统一 不同团队手写的规则命名、label、注释各不相同，跨团队对比 SLO 状态时根本对不齐。

✅ Sloth 的解法 一个 YAML 文件定义 SLO → Sloth 生成 19 条格式统一的规则 → promtool 验证 → 加载到 Prometheus。改 SLO 目标改一行，重新生成即可。

---

2 安装 Sloth

Sloth 提供三种安装方式，推荐 Docker 或二进制。

方式一：Docker（推荐）

# 拉取最新镜像
docker pull slok/sloth:latest

# 验证安装
docker run --rm slok/sloth:latest --version

# 生成规则
docker run --rm \
  -v $(pwd)/slo-config.yaml:/slo.yaml \
  -v $(pwd)/output:/output \
  slok/sloth:latest \
  generate -i /slo.yaml -o /output/slo-rules.yaml

方式二：二进制

# 下载最新 release（查看 https://github.com/slok/sloth/releases）
wget https://github.com/slok/sloth/releases/download/v0.16.0/sloth-v0.16.0-linux-amd64.tar.gz
tar xzf sloth-v0.16.0-linux-amd64.tar.gz
mv sloth /usr/local/bin/

# 验证
sloth --version

方式三：Go install

go install github.com/slok/sloth/cmd/sloth@latest

💡 CI/CD 集成建议：在 CI pipeline 中用 Docker 方式运行 Sloth，将生成的 slo-rules.yaml 提交到 Git 仓库。这样 SLO 变更有 code review，规则变更可追溯——这是 GitOps 的标准做法。

---

3 5 分钟上手：第一个 SLO

从一个最简单的 HTTP 服务可用性 SLO 开始。

Step 1：编写 SLO 声明文件

# slo-config.yaml
# Sloth 使用 prometheus/v1 作为 spec 版本

version: "prometheus/v1"
service: "myservice"
labels:
  owner: "myteam"
  repo: "myorg/myservice"
  tier: "2"

slos:
  - name: "requests-availability"
    objective: 99.9          # SLO = 99.9%
    description: "HTTP 请求可用性 SLO"
    labels:
      category: "availability"

    sli:
      events:
        # {{.window}} 是 Sloth 模板变量
        # 生成时会替换为 5m/30m/1h/2h/6h/1d/3d 等窗口
        error_query: |
          sum(rate(http_request_duration_seconds_count{
            job="myservice",
            code=~"(5..|429)"
          }[{{.window}}]))
        total_query: |
          sum(rate(http_request_duration_seconds_count{
            job="myservice"
          }[{{.window}}]))

    alerting:
      name: "MyServiceHighErrorRate"
      labels:
        category: "availability"
      annotations:
        summary: "myservice 请求错误率过高"
      page_alert:
        labels:
          severity: "pageteam"
          routing_key: "myteam"
      ticket_alert:
        labels:
          severity: "slack"
          slack_channel: "#alerts-myteam"

这里有几个关键字段需要理解：

字段	作用	必填
version	Spec 版本，目前为 "prometheus/v1"	是
service	服务名，会写入所有生成规则的 sloth_service label	是
labels	全局标签，附加到所有生成的规则上	否
slos[].name	SLO 名称，写入 sloth_slo label	是
slos[].objective	SLO 目标值，如 99.9 表示 99.9%	是
slos[].sli.events	事件型 SLI，提供 error_query 和 total_query	是（选一种 SLI）
slos[].alerting	告警配置，包括 Page 和 Ticket 两级	否

🔑 {{.window}} 模板变量是核心设计 你在 error_query 和 total_query 中使用 {{.window}}，Sloth 会在生成时自动替换为 8 个窗口大小：5m、30m、1h、2h、6h、1d、3d、30d。这意味着你只需要写一次 PromQL，Sloth 自动生成 8 个不同窗口的 recording rules。

Step 2：生成 Prometheus 规则

# 生成规则文件
sloth generate -i slo-config.yaml -o slo-rules.yaml

# 用 promtool 验证生成结果
promtool check rules slo-rules.yaml

# 输出示例：
# Checking slo-rules.yaml
# SUCCESS: 19 rules found

Step 3：加载到 Prometheus

# prometheus.yml
rule_files:
  - "slo-rules.yaml"
  - "other-rules.yaml"

重启或 reload Prometheus 后，SLO 规则就生效了。整个流程：写 YAML → 生成 → 验证 → 加载，5 分钟完成。

---

4 SLI 类型详解

Sloth 支持两种内建 SLI 类型和插件机制。选对 SLI 类型是配置 Sloth 的关键。

类型一：events（最常用）

事件型 SLI，提供 error_query（错误事件数）和 total_query（总事件数），Sloth 自动计算 error / total。

sli:
  events:
    error_query: |
      sum(rate(http_requests_total{
        job="myservice",
        status=~"5.."
      }[{{.window}}]))
    total_query: |
      sum(rate(http_requests_total{
        job="myservice"
      }[{{.window}}]))

适用场景：HTTP API 可用性、gRPC 错误率、消息消费失败率。这是最推荐的 SLI 类型——直接符合 good_events / total_events 的 SLI 工程化定义。

类型二：raw（直接比率）

当你已经有了错误比率指标，或者 SLI 计算逻辑比较复杂不适合拆成 error/total 时，用 raw 类型直接提供错误比率查询。

sli:
  raw:
    error_ratio_query: |
      # 直接返回 0-1 之间的错误比率
      sum(rate(payments_failed_total{job="payment-api"}[{{.window}}]))
      /
      sum(rate(payments_total{job="payment-api"}[{{.window}}]))

适用场景：错误率来自不同指标源的复合计算，或者已有自定义指标直接输出错误比率。

⚠️ raw 类型的注意事项 raw 类型的 error_ratio_query 必须返回 0 到 1 之间的值。如果你的查询返回的是百分比（0-100），需要除以 100。另外，raw 类型在低流量时段可能产生除零错误——建议在查询中加入 clamp_min(total, 1) 来防止除零。

类型三：SLI 插件

Sloth 支持通过插件扩展 SLI 类型。社区维护了一个常用 SLI 插件库，包括 HTTP、gRPC、Kubernetes 等场景的现成 SLI。

sli:
  plugin:
    id: "sloth-common/http/metadata"
    options:
      service: "myservice"
      error_status_codes:
        min: 500
        max: 599

插件的好处是屏蔽 PromQL 细节，让非 SRE 人员也能定义 SLO。但代价是灵活性降低，且依赖外部插件维护。

---

5 理解 Sloth 生成的规则

这是本文最核心的部分——理解 Sloth 到底生成了什么。只有看懂了生成输出，才能在 Grafana 里查对指标、在 Alertmanager 里配对路由。

一个 SLO 会生成 3 组规则：

第一组：SLI Recording Rules（8 条）

每个窗口大小生成一条错误率 recording rule，命名格式为 slo:sli_error:ratio_rate{window}：

• slo:sli_error:ratio_rate5m — 5 分钟窗口错误率
• slo:sli_error:ratio_rate30m — 30 分钟窗口错误率
• slo:sli_error:ratio_rate1h — 1 小时窗口错误率
• slo:sli_error:ratio_rate2h — 2 小时窗口错误率
• slo:sli_error:ratio_rate6h — 6 小时窗口错误率
• slo:sli_error:ratio_rate1d — 1 天窗口错误率
• slo:sli_error:ratio_rate3d — 3 天窗口错误率
• slo:sli_error:ratio_rate30d — 30 天窗口错误率（从 5m 聚合）

每条规则的 PromQL 就是你配置的 error_query / total_query，只是 {{.window}} 被替换成了对应的窗口。所有规则都带上 sloth_id、sloth_service、sloth_slo、sloth_window 这组 label，方便筛选。

第二组：Meta Recording Rules（7 条）

这些是 SLO 的元数据指标，不需要你配置，Sloth 自动生成：

指标名	含义	示例值
slo:objective:ratio	SLO 目标值	0.999（即 99.9%）
slo:error_budget:ratio	错误预算 = 1 - SLO	0.001（即 0.1%）
slo:time_period:days	SLO 统计周期	30
slo:current_burn_rate:ratio	当前燃烧率 = 5m错误率 / 错误预算	3.5（预算消耗速度是预期的 3.5 倍）
slo:period_burn_rate:ratio	周期燃烧率 = 30d错误率 / 错误预算	0.8（本月已消耗 80% 预算）
slo:period_error_budget_remaining:ratio	剩余预算比例 = 1 - 周期燃烧率	0.2（剩余 20%）
sloth_slo_info	SLO 元信息（版本、模式等）	1（仅用于 label 携带）

🔑 最实用的两个 Meta 指标slo:period_error_budget_remaining:ratio 直接告诉你"本月还剩多少错误预算"——这就是回答"这个月还能不能发版"的关键指标。

slo:current_burn_rate:ratio 告诉你"当前预算消耗速度是预期的几倍"——用于实时监控是否正在快速烧预算。

第三组：Alert Rules（2 条）

Sloth 生成 2 条 alert rule：一条 Page 级，一条 Ticket 级。每条内部用 OR 连接两组双窗口条件。

Page 级告警（立即通知）

# Sloth 生成的 Page 级告警表达式
(
  max(slo:sli_error:ratio_rate5m > (14.4 * 0.001)) without (sloth_window)
  and
  max(slo:sli_error:ratio_rate1h > (14.4 * 0.001)) without (sloth_window)
)
or
(
  max(slo:sli_error:ratio_rate30m > (6 * 0.001)) without (sloth_window)
  and
  max(slo:sli_error:ratio_rate6h > (6 * 0.001)) without (sloth_window)
)

解析这段表达式：

• 14.4 * 0.001 = 燃烧率 14.4 × 错误预算 0.1% = 1.44%——当 5 分钟和 1 小时错误率都超过 1.44% 时告警
• 6 * 0.001 = 0.6%——当 30 分钟和 6 小时错误率都超过 0.6% 时告警
• and 是双窗口 AND 逻辑，or 是两组条件任一满足即告警
• max(...) without (sloth_window) 聚合掉 window label，避免重复告警

Ticket 级告警（工单跟进）

# Sloth 生成的 Ticket 级告警表达式
(
  max(slo:sli_error:ratio_rate2h > (3 * 0.001)) without (sloth_window)
  and
  max(slo:sli_error:ratio_rate1d > (3 * 0.001)) without (sloth_window)
)
or
(
  max(slo:sli_error:ratio_rate6h > (1 * 0.001)) without (sloth_window)
  and
  max(slo:sli_error:ratio_rate3d > (1 * 0.001)) without (sloth_window)
)

Ticket 级阈值更低（3× 和 1×），用于捕获慢性病消耗——当错误率持续略高于预算但不足以触发 Page 时，通过工单跟进。

💡 燃烧率阈值速查表 所有告警规则里的乘数（14.4、6、3、1）是 Google SRE Workbook 的标准值，Sloth 默认使用这些值。它们的含义是"预算消耗速度是预期的几倍"。乘数 × 错误预算 = 实际告警阈值。

级别	长窗口	短窗口	燃烧率	含义
Page	1h	5m	×14.4	2% 月预算 1 小时烧光
Page	6h	30m	×6	5% 月预算 6 小时烧光
Ticket	1d	2h	×3	10% 月预算 1 天烧光
Ticket	3d	6h	×1	10% 月预算 3 天烧光

---

6 实战：多服务多 SLI 配置

真实场景中，你需要为多个服务定义多个 SLI。Sloth 支持在一个 YAML 文件中定义一个服务的多个 SLO，也可以用多个文件管理多个服务。

一个服务，多个 SLO

# payment-api 多 SLI 配置
version: "prometheus/v1"
service: "payment-api"
labels:
  owner: "payments-team"
  tier: "1"

slos:
  # SLI-1: 可用性
  - name: "availability"
    objective: 99.9
    description: "支付 API 非 5xx 响应率"
    sli:
      events:
        error_query: |
          sum(rate(http_requests_total{
            job="payment-api", status=~"5.."
          }[{{.window}}]))
        total_query: |
          sum(rate(http_requests_total{
            job="payment-api"
          }[{{.window}}]))
    alerting:
      name: "PaymentAPIAvailability"
      page_alert:
        labels: { severity: "page" }
      ticket_alert:
        labels: { severity: "ticket" }

  # SLI-2: 延迟（事件级，非 P99）
  - name: "latency"
    objective: 99
    description: "支付请求 500ms 内完成率"
    sli:
      events:
        # 总事件 = 所有请求
        total_query: |
          sum(rate(http_request_duration_seconds_count{
            job="payment-api"
          }[{{.window}}]))
        # 错误事件 = 耗时超过 500ms 的请求
        # 用 histogram bucket 的 _count 减去 le=0.5 的 bucket
        error_query: |
          sum(rate(http_request_duration_seconds_count{
            job="payment-api"
          }[{{.window}}]))
          -
          sum(rate(http_request_duration_seconds_bucket{
            job="payment-api", le="0.5"
          }[{{.window}}]))
    alerting:
      name: "PaymentAPILatency"
      page_alert:
        labels: { severity: "page" }
      ticket_alert:
        labels: { severity: "ticket" }

  # SLI-3: 饱和度（DB 连接池）
  - name: "db-saturation"
    objective: 99.5
    description: "DB 连接池使用率低于 90%"
    sli:
      raw:
        # 直接返回错误比率 = 超过 90% 使用率的时间占比
        error_ratio_query: |
          avg_over_time(
            (db_connections_active{job="payment-api"}
             / db_connections_max{job="payment-api"}) > 0.9
          [{{.window}}])
    alerting:
      name: "PaymentAPIDBSaturation"
      page_alert:
        labels: { severity: "page" }
      ticket_alert:
        labels: { severity: "ticket" }

💡 延迟 SLI 的巧思 延迟 SLI 用 events 类型实现：总事件是所有请求，错误事件是"慢请求"（耗时超过阈值的请求）。关键技巧是用 histogram bucket 的 _count 减去 le="0.5" 的 bucket，得到"超过 500ms 的请求数"。这比用 P99 更符合 SLI 公式，且天然适配燃烧率告警。

多服务管理

每个服务一个 YAML 文件，统一生成：

# 目录结构
slo-configs/
  payment-api.yaml
  user-service.yaml
  order-service.yaml

# 批量生成
for f in slo-configs/*.yaml; do
  sloth generate -i "$f" -o "rules/$(basename ${f%.yaml}).rules.yaml"
done

# 批量验证
for f in rules/*.yaml; do
  promtool check rules "$f" || echo "FAILED: $f"
done

CI/CD 集成

# .gitlab-ci.yml 示例
slo-rules:
  stage: generate
  image: slok/sloth:latest
  script:
    - mkdir -p rules
    - for f in slo-configs/*.yaml; do
        sloth generate -i "$f" -o "rules/$(basename ${f%.yaml}).rules.yaml";
      done
    - for f in rules/*.yaml; do
        promtool check rules "$f";
      done
    - git add rules/
    - git commit -m "chore: regenerate SLO rules" || true
  artifacts:
    paths:
      - rules/

---

7 告警配置与路由

告警结构详解

Sloth 生成的每条 alert 都带有一组标准 label，用于 Alertmanager 路由：

Label	来源	用途
sloth_severity	Sloth 自动添加	page 或 ticket，用于路由
sloth_service	配置文件的 service	按服务筛选
sloth_slo	SLO 的 name	按 SLO 筛选
severity	你在 page_alert / ticket_alert 中定义	自定义路由 key
其他自定义 label	你在 labels 中定义	按团队、类别等路由

Alertmanager 路由配置

route:
  group_by: ["sloth_service", "sloth_slo"]
  group_wait: 10s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    # Page 级 → 电话/短信/IM
    - matchers:
        - sloth_severity = "page"
      receiver: oncall-phone
      group_wait: 0s
      repeat_interval: 30m

    # Ticket 级 → 工单系统
    - matchers:
        - sloth_severity = "ticket"
      receiver: ticket-system
      group_wait: 5m
      repeat_interval: 12h

    # 按团队路由（覆盖默认）
    - matchers:
        - sloth_severity = "page"
        - owner = "payments-team"
      receiver: payments-oncall

receivers:
  - name: oncall-phone
    webhook_configs:
      - url: "https://oncall.example.com/api/alert"

  - name: payments-oncall
    webhook_configs:
      - url: "https://oncall.example.com/api/alert/payments"

  - name: ticket-system
    webhook_configs:
      - url: "https://ticket.example.com/api/create"

禁用特定告警

有些 SLO 你只想看数据不想告警，或者只想 Page 不想 Ticket：

slos:
  - name: "experimental-slo"
    objective: 99
    sli:
      events:
        error_query: "..."
        total_query: "..."
    alerting:
      name: "ExperimentalSLO"
      # 禁用 Ticket 级告警
      ticket_alert:
        disable: true
      # 保留 Page 级
      page_alert:
        labels:
          severity: "page"

---

8 Grafana 可视化

Sloth 官方提供了一个现成的 Grafana dashboard（Dashboard #14348），导入即用。但理解关键 PromQL 查询能帮你自定义面板。

关键面板的 PromQL

错误预算燃烧进度

# 本月错误预算已消耗百分比
1 - slo:period_error_budget_remaining:ratio{
  sloth_service="payment-api"
}

# 剩余错误预算时间（分钟）
slo:period_error_budget_remaining:ratio{
  sloth_service="payment-api"
} * 43200  # 30天 = 43200分钟

实时燃烧率

# 当前 5 分钟窗口燃烧率
slo:current_burn_rate:ratio{
  sloth_service="payment-api",
  sloth_slo="availability"
}

# 燃烧率超过 1 表示预算消耗快于预期
# 超过 14.4 表示即将触发 Page 告警

SLO 达成状态总览

# 所有 SLO 的当前错误率 vs 目标
slo:sli_error:ratio_rate5m
* 100  # 转百分比

# 对比 SLO 目标
slo:objective:ratio * 100

导入官方 Dashboard

1. Grafana → Dashboards → Import：输入 Dashboard ID 14348
2. 选择 Prometheus 数据源：选择你的 Prometheus 实例
3. 使用 Variables 筛选：Dashboard 内置了 sloth_service 和 sloth_slo 变量，可以在顶部下拉切换服务和 SLO

---

9 高级用法

Kubernetes Operator 模式

在 Kubernetes 环境下，Sloth 可以作为 Operator 运行，通过 CRD（Custom Resource Definition）管理 SLO：

# Helm 安装 Sloth operator
helm repo add slok https://slok.github.io/sloth-charts/
helm install sloth slok/sloth \
  --namespace sloth-system \
  --create-namespace \
  --set kubernetes.enabled=true

# 定义 SLO CRD
apiVersion: sloth.slok.dev/v1
kind: PrometheusServiceLevel
metadata:
  name: payment-api
  namespace: payments
spec:
  service: "payment-api"
  labels:
    owner: "payments-team"
  slos:
    - name: "availability"
      objective: 99.9
      sli:
        events:
          error_query: |
            sum(rate(http_requests_total{
              job="payment-api", status=~"5.."
            }[{{.window}}]))
          total_query: |
            sum(rate(http_requests_total{
              job="payment-api"
            }[{{.window}}]))
      alerting:
        name: "PaymentAPIAvailability"
        page_alert:
          labels: { severity: "page" }
        ticket_alert:
          labels: { severity: "ticket" }

Operator 模式的优势：SLO 定义作为 Kubernetes 资源管理，可以用 GitOps（ArgoCD/Flux）自动同步，每次 SLO 变更自动重新生成 PrometheusRule 资源。

OpenSLO 格式支持

Sloth 支持读取 OpenSLO 格式的 SLO 定义，这是跨工具的 SLO 标准：

# 使用 OpenSLO 格式生成
sloth generate --input-type openslo -i slo-openslo.yaml -o slo-rules.yaml

好处是如果你的 SLO 定义需要在 Sloth、Nobl9、Datadog 等不同工具间共享，可以用 OpenSLO 作为统一格式。

validate 命令（CI 集成）

# 验证 SLO 配置文件（不生成规则）
sloth validate -i slo-config.yaml

# 在 pre-commit hook 中使用
# .pre-commit-config.yaml
# - id: sloth-validate
#   name: Validate SLO specs
#   entry: sloth validate -i
#   language: system
#   files: slo-configs/.*\.yaml$

自定义 SLO 周期

默认 30 天周期，可以改为 28 天（对齐四周一个迭代）：

version: "prometheus/v1"
service: "myservice"

# 自定义 SLO 周期
slos:
  - name: "availability"
    objective: 99.9
    # 28 天周期（4 周）
    sli: { ... }
    alerting: { ... }

⚠️ 周期变更的影响 更改周期会影响 30d recording rule 的计算窗口。Sloth 默认使用 30 天和 28 天两个安全周期（避开月度天数不一致的问题）。如果你需要其他周期，确保 recording rules 中的 30d 窗口也同步调整。

---

10 避坑指南

⚠️ 坑1：低流量时段 SLI 除零 凌晨 3 点 QPS 趋近于 0，error_events / total_events 变成 0/0 = NaN，Grafana 面板断线，燃烧率计算异常。

解法：在 total_query 中加 clamp_min：clamp_min(sum(rate(...)), 0.001)，确保分母永远不为零。

⚠️ 坑2：label 冲突导致规则覆盖 两个 SLO 用了相同的 name，生成的 recording rules 会因为 label 完全一致而互相覆盖。

解法：每个 SLO 的 name 必须在同一个 service 下唯一。Sloth v0.16+ 已增加重复检查，但旧版本不会报错。

⚠️ 坑3：Prometheus 规则加载失败静默 生成的 YAML 语法错误或 PromQL 无效，Prometheus 会在启动日志里报错但不会停止运行——你可能直到下次告警没触发才发现规则没加载。

解法：在 CI 中用 promtool check rules 验证，部署后用 promtool query instant http://prometheus:9090 'sloth_slo_info' 确认规则已加载。

⚠️ 坑4：objective 精度问题 Sloth 生成的规则中，slo:objective:ratio 的值可能是 0.9990000000000001（浮点精度问题）。这在大部分场景无影响，但如果你的告警逻辑依赖精确比较，注意用 round() 处理。

⚠️ 坑5：忘记 reload Prometheus 更新了 slo-rules.yaml 但没 reload Prometheus，旧规则继续运行。用 POST /-/reload 或 kill -HUP 触发 reload，并确认 up{job="prometheus"} 正常。

---

11 Sloth vs Pyrra：怎么选

Sloth 和 Pyrra 是两个最常用的 Prometheus SLO 生成工具，选择取决于你的场景：

维度	Sloth	Pyrra
定位	CLI 工具 + K8s Operator	K8s-native（CRD 优先）
配置格式	YAML / OpenSLO	CRD（Kubernetes 原生）
SLI 类型	events / raw / plugins	ratio（更简洁）
Web UI	内置 SLO 浏览器	内置 dashboard
非 K8s 场景	支持（CLI 模式）	不支持
插件生态	社区插件库	较少
OpenSLO 支持	支持	不支持
推荐场景	混合环境、需要 CLI、多工具协作	纯 K8s 环境、偏好 CRD 管理

---

结语：把重复劳动交给工具

SLO 体系的核心价值在于决策——能不能发版、要不要回滚、优先修哪个故障。这些决策需要的是准确的数据和及时的告警，而不是工程师花时间手写 171 条 PromQL 规则。

Sloth 把 SLO 的工程实现标准化了：

• 声明式：YAML 定义"我要什么"，Sloth 生成"怎么做"
• 可验证：validate + promtool 双重校验，CI 集成
• 统一格式：所有团队、所有服务的 SLO 规则格式一致，label 统一
• GitOps 友好：YAML → Git → CI → Prometheus，变更有审计、可回滚

把重复劳动交给工具，把精力留给真正需要人的判断——SLI 选型、SLO 目标设定、错误预算运营策略。这才是 SRE 工程化的本质。

上一篇讲了 SLO 体系"是什么、为什么"，这篇讲的是"用什么工具做、怎么做好"。两篇合起来，就是 SLO 从 0 到 1 的完整工程路径。

---

SRE 实战手册 · 工具实战系列Sloth 项目地址: github.com/slok/sloth | 官方文档: sloth.dev